Deep in the Heart of Smalltalk 


The active life is the 
life for me! 



A lmost everything in Smalltalk is an object, including 
language elements likeclasses, methods, processes, 
l and contexts. Variables area major exception to this 
ruleof thumb. Whileglobal and class variables are objects 
in most implementations of Smalltalk, instance variables 
and temporary variables are not. That’s too bad, because 
instance variables have many uses as objects. (Making 
temporary variables first-class seems less useful.) 

For example, user interface widgets often wish to de¬ 
pend on a particular attribute of an object. VisualWorks 
has you represent these attributes with ValueHolders, 
which are objects that hold a single value. If you store an 
attribute in a ValueH older, widgets can depend on the 
ValueH older and be notified when that attribute changes. 
However, to change a design that doesn’t use ValueHolders 
to one that does, you have to rewrite your program, 
changing accesses to attributes stored in ValueHolders. 
There are times when you want to keep the program as it 
is, butjust change the way you store the attribute. In other 
words, you’d I ike to depend directly on a variable without 
explicitly having to store a ValueH older in it. This feature is 
called active variables* and is very useful when you are 
debugging and fine-tuning a program. 

In this column we use VisualWorks 2.0 to implement 
active variables in three steps. First, we define the class 
ActiveVariable and show how to convert an object’s slots 
to contain instances of it. Next, in the largest step, we 
introduce a new class for an object containing one or 
more ActiveVariables. Finally, we use a new kind of 
MethodProducer to recompile methods in the new class. 
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ACTIVE IS AS ACTIVE DOES 

To our knowledge, the first language to include active vari¬ 
ables was LOOPS. Active variables descended to CLOS in 
the form of access daemons on slots. We’re not the fi rst to 
implement active variables in Smalltalk (see Messick 1 for 
example), and our specification is similar to what others 
have done. Our implementation of ActiveVariables is new, 
since we use the GenericCompiler and MethodProducer de¬ 
scribed in our previous columns. ActiveVariables satisfy the 
following high-level specification: 

Class: ActiveVariable 

Superclass: Object 
Important instance variables: 

name <String> 
value <0bject> 

readDependents <Set of 2-argument BlockClosures> 
writeDependents <Set of 3-argument BlockClosures> 

Important instance methods: 

value 

Return theActiveVariable's value, and also notify 
readDependents. 

value: anObject 

Set theActiveVariable's value, and also notify 
writeDependents. 

The read dependents are two-argument blocks, whose 
parameters are the ActiveVariable and its current value. 
These blocks are evaluated whenever the message #value 
is sent to the ActiveVariable, as fol lows: 

Method for ActiveVariable 

value 

readDependents do: [ :each | each value: self value: 

value]. 

Walue 

Similarly, the write dependents are evaluated whenever 


* Source code for the active variables package is available by anony- 
mousftp fromst.cs.uiuc.edu. Lookforthefile ActiveVariables20.st 
in pub/st_vw. 
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#value: is sent to the ActiveVariable. They are three-argu¬ 
ment blocks, whose parameters are the ActiveVariable, its 
current value, and its old, over-written value: 

Method for ActiveVariable 

value: anObject 

'This method needs to return the new (i.e., being set) 
value, so the behavior is consistent when an 
ActiveVariable set replaces a : = expression." 

| oldValue | 
oldValue : = value. 
value : = anObject. 

writeDependents do: [ :each | each value: self value: 
value value: oldValue]. 

''value 

ActiveVariables are added to an object using #instVarAt:put:, 
the primitive method that gives direct access to object 
state While this method is a gross violation of encap¬ 
sulation, it’s required for Smalltalk programming tools 
written in Smalltalk, such as the Inspector. We use the 
phrase "activating an object" to describe the process of 
adding ActiveVariables to the object’s slots, and similarly 
define an "activated object" to be an object that has 
ActiveVariables implicitly stored in some of its slots. Once 
an object has been activated, its class must be changed, 
and ideally the slot conversion and class change should 
happen atomically, to prevent access errors The object’s 
new class has methods re-compiled to send #value and 
#value: to access any activated slots. We show how to 
create such a class in the next two sections. 

ACTIVATED OBJ ECTS NEED ACTIVE CLASSES 

Since an activated object needs specially compiled meth¬ 
ods, it also needs a special class to store those methods. 
Furthermore, this class must be distinct for different 
objects, so that you can activate one of a class’s instances 
without activating all of them. This kind of class, which 
is distinct for individual objects, is called a lightweight 
class, which we showed how to implement in Debugging 
Objects. 2 Activated objects are instances of ActiveClass, 
which is a new subclass of LightweightClass that adds 
specialized support for ActiveVariables. In addition, each 
ActiveClass needs some information for each of its vari¬ 
ables that is activated. A new object called ActiveVariable- 
Specification maintains this information fortheActiveClass. 
These two new classes are specified by 

Class: ActiveClass 

Superclass: LightweightClass 

Important instance variables: 

baseClass <Class> 

activeVariables<Collection of ActiveVariableSpecifications> 

Important instance methods: 

activateObject: <0bject> 

Create and install ActiveVariables in slots of the Object corre¬ 
sponding to the receiver's ActiveVariableSpecifications. 


activeVariables 
activeVariablel ndexes 

Return respectively the collection of names and indexes of 
this ActiveClass' activated variables. 
allActiveVariables 
allActiveVariablel ndexes 

Return respectively the collection of names and indexes of all 
activated variables in this ActiveClass and all of its transitive 
superclasses. 

convertl nstancesTo: <ActiveClass> addedl ndexes: 
Collection of Small I ntegers> from: <Behavior> 

Convert any instances of the receiver to have the input 
ActiveClass as their class. This involves changing their class, 
adding ActiveVariables to any slots numbered in the input col¬ 
lection, and recompiling methods that reference those slots. 
noteNewActiveVariables: Collection of 

Acti veVariableSpecifi cations> 
Stores any new ActiveVariableSpecifications in the active¬ 
Variables instance variable and converts the receiver's in¬ 
stances to support these specifications. 

Important class methods: 

destroyAIIActiveClasses 

Eliminates all active classes and their instances 

Class: ActiveVariableSpecification 

Superclass: Object 
Important instance variables: 

name <String> 

index <Smalllnteger> 

gl obal ReadDependents <0rd eredCo 11 ecti o n of 2-argument 
BlockClosures> 

globalWriteDependents CrderedCollection of 3-argument 
BlockClosures> 

localReadDependents <1 dentityDictionary mapping 
objects to 2-argument 
BlockClosures> 

localWriteDependents <1 dentityDictionary mapping 
objects to 3-argument 
BlockClosures> 

Important instance methods 

addDependentsFrom: <Acti veVariableSpecifi cation > 

Merges the ActiveVariableSpecification's dependents lists 
into the receiver's. 
setDependentsOf: <0bject> 

Adds dependent blocks to the ActiveVariable in the Object's 
slot indicated by the receiver's index instance variable. All 
blocks from the global lists are added, as well as any associ¬ 
ated with the Object in the local dictionaries. 

setReadDependents: Collection of 2-argument 
BlockClosures> 

setWriteDependents: Collection of 3-argument 
BlockClosures> 

Respectively set the read- and write-dependent 
collections for this specification. 

ActiveClasses create a new distinction between two kinds of 
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LightweightClass. Originally, a LightweightClass acted as an 
extension of an object’s original class TheLightweightClass 
stood between the object and its original class, allowing 
the object to inherit methods from the original class as 
long as they weren't over-ridden in the LightweightClass. 
Most ActiveClasses will not be extensions of the original 
class, butinstead they will completely replace theoriginal 
class in the object’s look-up chain. 

Figure 1 illustrates these two different arrangements. 
In this example, aSetl and aSet2 were both instances of 
Set, whose superclass is Collection. An extension 
LightweightClass named ExtensionToSet was created for 
aSetl and inserted between aSetl and Set. A replacement 
LightweightClass named ReplacementForSet was created for 
aSet2 and inserted between it and Collection, effectively 
removing Set from aSet2's lookup chain. aSetl responds to 
#size using the method defined in Set, its original class, 
since that method is not over-ridden in ExtensionToSet. 
However, it responds to #isEmpty using the method 
defined in ExtensionToSet (which could still refer to Set’s 
method #isEmpty by a super send). On the other hand, 
aSet2 respondsto #size using the method from Collection. 
It responds to #isEmpty using the method defined in 
ReplacementForSet, which cannot access Set's method 
#isEmpty since Set is nowhere on Replacment ForSet’s 
superclass chain. 

There are two reasons why ActiveClasses are best imple¬ 
mented asreplacementLightweightClasses. First,significant 
spacecan be saved when objects are activated fromseveral 
classes in one class hierarchy. If ActiveClasses were exten¬ 
sions, and a DependentPart object and a CompositePart object 
were activated, the DependentPart's ActiveClass and the 
CompositePart'sActiveClass would both haverecompiled ver- 



Figure l.The difference between extension and replacement 
LightweightClasses. 


sions of methods from their common superclasses. With 
ActiveClasses implemented as replacements, though, the 
two ActiveClasses would both inherit from an ActiveClass for 
VisualPart, eliminating that method duplication. The sec¬ 
ond justification isthat extension classes must change the 
way they compi le methods that use su per. Usi ng the same 
example, if a VisualPart method referencing super were 
naively recompiled in the DependentPart’s ActiveClass, super 
would refer to VisualPart and not Object. Using replace¬ 
ments, the ActiveClass hierarchy parallels the original class 
hierarchy, guaranteeingthatthemeaningof super in recom¬ 
pi led methods will remai n correct. 

Using replacements instead of extensions doesn’t re¬ 
move all technical difficulties, of course. For example, 
suppose three objects with the same class are activated, 
only each activates a different subset of the class’s vari¬ 
ables. How many ActiveClasses should be created? On one 
extreme, we could create three ActiveClasses, one for each 
object. Should another object of the same class be ac¬ 
tivated in exactly the same slots, it could share the 
ActiveClass of one of these three, but otherwise a new 
ActiveClass would be required. This answer guarantees 
that each ActiveClass minimally matches its instances’ 
needs for activation, but also has the potential to waste 
space. On the other extreme is the solution we’ve adopt¬ 
ed, which uses only one ActiveClass for every class. In the 
above scenario, thisActiveClass will activate all slots need¬ 
ed by any one of its activated instances. As a result, some 
objects will have variables activated unnecessarily. This 
will not cause any incorrect behavior, though it will 
unnecessarily (but insignificantly, in our opinion) slow 
the objects’ access to their variables. As another result, a 
new instance variable named activeVersion is added to 
Behavior, and thusto every existing and added class in the 
system. This variable will either hold the Behavior's 
unique active version or nil if it has none. In addition, 
we’ve added a number of new methods to Behavior. These 
new additions are summarized by 

Class: Behavior 

Added instance variables: 

activeVersion <niI | ActiveClass> 

Added instance methods 

activateObject: <0bject> 

variablel ndexes: Collection of Small I ntegers> 

readDependents: Collection of 2-argument 

BlockClosures> 

writeDependents: Collection of 3-argument 
BlockClosures 

InstallsActiveVariables in all slots of the Object indicated in 
the #variablel ndexes: parameter. Adds the given read- and 
write-dependents to these ActiveVariables. Changes the 
Object’s class to an appropriate ActiveClass. 

activeSuperclass 

If the Behavior's activeVersion isn’t nil, returns the active 
Version's superclass. Otherwise returns the Behavior's 
superclass. 
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buiIdActiveClassForVariables: <Collection of 

ActiveVariableSpecifications> 
bui IdActiveClassForVariables: <Collection of 

ActiveVariableSpecifications> 
from: <Behavior> 

Do whatever work is necessary, which can sometimes be 
quite a lot, to build an ActiveClass that activates all slots 
indicated by the input collection. 

buildActiveSu perclassForVariables: 

Collection of ActiveVariableSpecifications> 

Obtains an ActiveClass for theBehavi or’s superclass that ac- 
tivates any variables in the input collection that are de¬ 
fined in that superclassor higher. 

You activate an object by sending it #activateVariables: 
readDependents:writeDependents:. The first parameter is a 
collection of variable names to be activated, and the last 
two respectively are col lections of read- and write-depen- 
dent blocks to be registered for all the slots being activat¬ 
ed. The implementation in Object forwards the message to 
Behavior, which implements it as: 

Method for Behavior 

activateObject: object variablel ndexes: indexCollection 
readDependents: readBlocks writeDependents: 
writeBlocks 

| specs activeClass names | 
names : = self alii nstVarNames. 
specs: = indexCollection collect: [ :each | 
self activeVariableSpecClass new 
name: (names at: each) index: each; 
setReadDependents: readBlocks for: object; 
setWriteDependents: writeBlocks for: object], 
activeClass : = self buiIdActiveClassForVariables: specs. 
activeClass activateObject: object 

This method has three major steps, corresponding to its 
last three statements. The #collect: loop creates an Active 
VariableSpecification for each slot. A dependent registered 
with an ActiveVariableSpecification can be associated with 
one particular activated object, as is done above, or it can 
be registered globally. With the latter option, you can 
monitor all accesses to a particular variable across a 
group of activated objects. The second step sends 
#buiIdActiveClass ForVariables: to create an ActiveClass that 
re-compiles all methods referencing variables in index 
Collection.Thefinal statement sends #acti vateObject: to the 
activeclass, which isdefined as: 

Method for ActiveClass 

activateObject: object 

| oldActiveVariablel ndexes newActiveVariablel ndexes 
names | 

oldActiveVariablel ndexes : = object dispatchingClass 

allActiveVariablel ndexes. 
(newActiveVariablel ndexes : = self 
allActiveVariablel ndexes) 


removeAll: oldActiveVariablel ndexes. 
names := baseClass alii nstVarNames. 
newActiveVariablel ndexes do: [ :each | 
object instVarAt: each put: 

(self activeVariableClass 
name: (names at: each) 
initialValue: (object instVarAt: each))], 
object changeClassToThatOf: self basicNew. 
self allActiveVariables do: [ :each | 
each setDependentsOf: object] 

The bulk of this message (up to the#changeClassToThatOf: 
send) creates and installs ActiveVariables in the newly acti¬ 
vated slots of the input object. It's important to install 
ActiveVariables only in newly activated slots, since other¬ 
wise the code could produce limitless chains of nested 
ActiveVariables.Theinitial valueforeach newActiveVariable 
is the old (non-active) value for the corresponding slot. 
After the ActiveVariables are installed, the receiver be¬ 
comes the activated object’s new class (and, as we men¬ 
tioned before, this should ideally happen atomically with 
thesl ot conversion). Finally, theActiveVariableSpecifications 
help i nitial ize the newly acti vated object by copyi ng thei r 
read- and write-dependents for that object, as well as all 
global dependents. 

Behaviors respond to the #buiIdActiveClassForVariables: 
message used above by sending themselves #buildActive 
ClassForVariables:from: with the second parameter equal to 
self. This method constructs an ActiveClass for a given set 
of ActiveVariableSpecifications, which may require creating 
ActiveClasses for superclasses or converting existing 
ActiveClasses to support newly activated slots. Converting 
an existing ActiveClass may require work on its subclasses, 
since newly activated slots require the installation of 
ActiveVariables and the re-compilation of all referencing 
methods in the class’s instances and also in the instances 
of any classes that inherit from it. Thus, the method that 
does the conversion (which has the longish name 
#convertActiveClassWithSuperclass:addNewActiveVariables:fr 
om:) callsbackto #buildActiveClassForVariables:from: again. 
The sendingClass is passed in to ensure that every class 
gets converted only once. 

Method for Behavior 

bui IdActiveClassForVariables: variableSpecs from: 

sendingClass 

| newActiveSuperclass | 

newActiveSuperclass : = self buildActiveSuperclass 
ForVariables: variableSpecs. 

self activeClass notNil 

ifTrue: [self convertActiveClassWithSuperclass: 
newActiveSuperclass 
addNewActiveVariables: variableSpecs 
from: sendingClass] 

ifFalse: [self buiIdActiveClassWithSuperclass: 
newActiveSuperclass 
withVariables: variableSpecs]. 

"self activeClass 
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#buiIdActiveSuperclassForVariables: generates an ActiveClass 
for the superclass if it defines any of the activated slots. It 
does so with another send of #buiIdActiveClassForVariables: 
from:, passing in the receiver as the sendingClass. The 
superclass needs to know who originated the recursive 
message to eliminate redundant operations during its 
activation. 

Method for Behavior 

buiIdActiveSuperclassForVariables: variableSpecs 
| superclassActivatedSlots | 
superclassActivatedSlots : = 

variableSpecs select: [ :each | each index between: 

1 and: self superclass instSize], 

''superclassActivatedSlots isEmpty 
ifTrue: [ 

self activeSuperclass] 
ifFalse: [ 

self superclass 

bui IdActiveClassForVariables: 
superclassActivatedSlots 
from: self] 

The method #convertActiveClassWithSuperclass:addNewActive 
Variables:from: is called from #buildActiveClassForVariables: 
from: when the receiver already has an activated version. 
It builds a new ActiveClass, figures out exactly which var¬ 
iables are newly activated, and then converts instances 
of the old ActiveClass to the new format using #convert- 
I nstancesTo:addedl ndexes:from:. 

Method for Behavior 

convertActiveClassWithSuperclass: newSuperclass 
addNewActiveVariables: variableSpecs from: sendingClass 
| myActivatedSlots activeClass newActiveClass 
addedlndexes | 
myActi vatedSlots : = 


Figure 2. How activation spreadsthroughoutthe class hierarchy. 


variableSpecs select: [ :each | each index between: 
self superclass instSize +1 and: self instSize]. 
activeClass: = self activeClass. 
myActi vatedSlots : = myActi vatedSlots, (newSuperclass 
variableSpecsNotl ncludedln: activeClass superclass). 
newActiveClass : = activeClass copy. 
newActiveClass 

assignSuperclass: newSuperclass; 
noteNewActi veVari ables: myActi vatedSlots. 
addedl ndexes := myActi vatedSlots asOrderedCol lection 
collect: [ :each | each index], 

addedlndexes removeAll: activeClass 
allActiveVariablelndexes ifAbsent: []. 
activeClass 

convertl nstancesTo: newActiveClass 
addedlndexes: addedlndexes 
from: sendingClass. 
activeVersion := newActiveClass 

The variable myActivatedSlots contains the activated vari¬ 
ables that are defined in the receiver, plus any newly 
activated slots in newSuperclass. We need to allow for 
active superclasses that activate more variables than we 
request since every Class has just one ActiveClass version. 
For example, suppose we activate the variable "icon" in 
a ScheduledWindow and later activate the variables 
"application" and "label" in an ApplicationWindow. 
ApplicationWindow defines "application", but its superclass 
ScheduledWindow defines "label", so the activation 
process has to obtain an ActiveClass for ScheduledWindow 
using #buildActive SuperclassForVariables:. This ActiveClass 
will activate "label", as desired, but it will also activate 
"icon" because of the previous request. This technical 
point is an easy one to overlook in an implementation. 
(Or so wed like to think, since we missed it in our earli¬ 
est efforts!) 

Figure 2 illustrates how activation spreads around the 
class hierarchy and why it's important to 
identify the source of the 
#bu i Id Act iveCI assForVari ables:from: mes¬ 
sage. In the diagram, the dashed arrows 
represent the superclass relationship, and 
thethick arrows represent message sends. 
If "widgetFlags", "components", and "con¬ 
tainer" are activated for aBorderDecorator, 
activation must spread up from 
Acti veBorderDecorator to 

ActiveCompositePart, where "components" 
is defined, and to ActiveVisualPart, where 
"container" is defined. When 
ActiveCompositePart recompiles methods 
to activate "container” and "components", 
it must also update al I of its i nstances and 
all of its transitive subclasses’ instances. 
Flowever, these activation echoes must 
spread away from the 
Acti veBorderDecorator Acti veCompositePart- 
ActiveVisualPart branch, since their meth¬ 
ods and instances will be converted as a 
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result of #bui IdActi veClassForVariables:from: sends active for 
each of them. Thus, when ActiveCompositePart activates 
"container" and "components", it will send #convertVarsToA 
ctive: to ActiveDependentComposite but not to Active- 
BorderDecorator. Similarly, when ActiveVisualComponent 
activates "container", it will send #convertVarsToActive: to 
Acti veDependentPart (and thus indirectly to ActiveView) but 
notto ActiveCompositePart. 

The method #convertlnstancesTo:addedlndexes:from: is 
used when an existing Acti veClass is changed by the addi¬ 
tion of new ActiveVariables. It converts all the instances of 
the old ActiveClass to the new one. The argument index- 
Collection indicates the newly activated variables. 

Method for ActiveClass 

convertl nstancesTo: newActiveClass addedl ndexes: 
indexCollection from: sendingClass 
| templateObject instances | 

(instances := self alii nstances) isEmpty 
ifFalse: [ 

templateObject : = newActiveClass basicNew. 
self convertl ndexesToActive: indexCollection in: 

instances. 

instances do: [ :each | 

each changeClassToThatOf: templateObject]. 
newActiveClass updatel nstanceDependentsI n: 
instances]. 

self subclasses do: [ :each | 
each baseClass = sendingClass 
ifFalse: [ 

each assignSuperclass: newActiveClass. 

each withAIISubclasses do: [ :sub | 

sub updatelnstancesForActivatedlndexes: 
indexCollection]]] 

The message #convertl ndexesToActive:in: cycles through 
the passed-in collection and creates an ActiveVariable for 
each newly activated slot. Each instance then hasitsclass 
changed to the new ActiveClass. The #updatel nstance¬ 
DependentsI n: message iterates over the old ActiveClass's 
instances and adds the dependents from its ActiveVariable 
Specifications. Finally, the old active class moves its sub¬ 
classes (except for sendingClass) to the new ActiveClass. It 
changes their superclass, and then has them and all of 
their subclasses acti-vate the appropriate slots and 
recompile methods that reference any newly activated 
slots. This step, finally, is where the sendingClass parame¬ 
ter is used. The sendingClass shouldn't be converted, but 
only other subclasses of the old ActiveClass. The 
sendingClass subclass itself is processed in a 
#activeClassForVariableSpecs:from: context lower down in 
the execution stack. When that context resumes, that 
sendingClass will be converted appropriately, so it's vital 
(to avoid duplicate ActiveVariables, for example) that it not 
be converted here. Thus, as figure 2 showed, when class 
activation flows up the class hierarchy, any activation 
echoes flowing back down the hierarchy must flow away 
from classes passed up as sendingClass parameters 


The method #bui IdActi veClassWithSuperclass:withVariables: 
is called from #buildActiveClassForVariables:from: when the 
receiving Behavior doesn’t already have an active version. 

Method for Behavior 

buiIdActiveClassWithSuperclass: newSuperclass 
withVariables: variableSpecs 

| myActi vatedSlots | 

myActivatedSlots : = variableSpecs select: [ :each | 
each index between: self superclass instSize +1 
and: self instSize]. 

activeVersion := (ActiveClass newWithBase: self) 
copyAI IMethods. 

myActivatedSlots : = myActivatedSlots, (newSuperclass 
variableSpecsNotl ncludedl n: 
activeVersion). 

activeVersion 

assignSuperclass: newSuperclass; 
noteNewActiveVari ables: myActivatedSlots 
In ActiveClass»copyAIIMethods, the new ActiveClass copies 
all methods defined in the receiving Class, which is its 
base class. The new ActiveClass inherits from thesuper- 
class determined earlier. In #noteNewActiveVariables:, the 
newActiveClass stores ActiveVariableSpecifications in its 
activeVariables instance variable and recompiles methods 
accessing activated slots to use#value and #value:. 

THE ACTIVE COMPILER 

The process of converting active classes relies on the 
#recompileMethodsReferencing: message, which is called 
whenever an ActiveClass' set of ActiveVariableSpecifications 
changes. 

Method for ActiveClass 

recompileMethodsReferencingAny: indexCollection 

I m | 

self selectors do: [ :each | 

m : = self compiledMethodAt: each. 

(m usesAny: indexCollection) 
ifTrue: [self recompile: each]] 

This method recompiles any method of the receiver that 
uses, by reading or by writing, any named slot whose 
index is in the parameter indexCollection. This recompila¬ 
tion ensures that all activated slots are accessed only by 
#valueand #value: sendsThese#valueand#value: access¬ 
es are inserted by a special object called ActiveProducer. 

ActiveProducer subclasses from the MethodProducers we 
discussed in our previous two columns. It introduces a 
new name scope, ActiveNameScope, which in turn creates 
an instanceof ActiveLocalScope for any ActiveClass. During 
compilation, local name scopes create instances of sub¬ 
classes of class Variablefor each namein a parse tree. The 
choice of subclass affects the code generated to access 
the variable. For example, InstanceVariable emits primi¬ 
tive bytecodes for direct instance access. StaticVariable, 
which is used for global names, emits more specialized 
code. When the compiler encounters a write to a vari¬ 
able, it sends #emitStorePop:value:from: to the corre- 
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sponding Variable object. StaticVariable implements this 
method as: 

emitStorePop: codeStream value: value from: assignment 
"Emit code to assign a value to the variable." 

self checkStore: codeStream from: assignment. 
codeStream pushConstant: binding, 
value emitValue: codeStream forAssignment: 
assignment. 

codeStream noteSourceNode: assignment. 
codeStream sendNoCheck: #value: numArgs: 1. 
codeStream pop 

The u nderl i ned statements are the ones that actual ly gen¬ 
erate code The first generates bytecodes to push the 
StaticVariable's binding, which will be an Association, onto 
the stack. The next causes the assigned value to generate 
its own bytecodes. The thi rd statement generates a #val u e: 
message send, which will store the assigned value into the 
Association's value instance variable. ActiveLocalScope in¬ 
stantiates a new class, Activel nstanceVariable, to represent 
active named slots. Activel nstanceVariable overrides the 
load- and store-emitting messages in a way similar to 
StaticVariable. For example: 

emitStorePop: codeStream value: value from: assignment 
"Emit code to assign a value to the variable." 

self checkStore: codeStream from: assignment. 
codeStream putLoadl nst: index scope: scope. 
value emitValue: codeStream forAssignment: 
assignment. 

codeStream noteSourceNode: assignment. 
codeStream sendNoCheck: #value: numArgs: 1. 
codeStream pop 

This is the same as StaticVariable’s implementation except 
for the underlined statement. In contrast to the Static- 
Variable above, theActiveVariable isaccessed usingthenor¬ 
mal load for an instance variable. Si nee this method gen¬ 
erates a #value: send, the #value: message will be sent 
to the ActiveVariable at run-time, allowing it to store the 
new value in its value instance variable and to alert its 
writeDependents. 

BecauseStaticVariables are compiled specially, they also 
require special handling in the Decompiler. Activel nstance- 
Variables don’t require this as implemented, si nee they are 
only supported by ActiveClasses, which never decompile 
their methods. If you are interested in supporting 
ActiveVariables on Classes, you will have to add analogous 
special handling for ActiveVariables to the Decompiler. 

CONCLUSION 

The implementation we’vedescribed can beused to mon¬ 
itor instance variable accesses on a per-object basis That’s 
useful in its own right, and in addition we'll use active vari¬ 


ables in our next column to implement watchpoints. Our 
watchpoints will be arbitrary expressions you can enter 
into a Debugger, which will then alert you if and when the 
value of the watchpoi nt expression ever changes. 

There are a few limitations of our implementation 
that bear further investigation. Most notably, once an 
active version of a class is created, there is no connec¬ 
tion between methods in the Class and its ActiveClass. 
Thus, you might change methods in or add methods to 
the class, but these changes would not be reflected in 
the ActiveClass. As a result of this limitation, you will 
have to purge ActiveClasses periodically after you’ve 
made programming changes. Some day we hope there 
will be a detailed dependency mechanism that would 
alert interested parties whenever a class’ definition 
changes. (In fact, such a mechanism is one of the many 
potential projects for a future column.) In that case, we 
could use the dependencies to keep ActiveClasses in 
synch with their base class. Another extension that you 
may find interesting to attempt is to support the activa¬ 
tion of indexed instance variables as well as named 
instance variables. In some ways this is an easier prob¬ 
lem, since indexed variables can only be accessed via 
messages, but there are still some interesting issues 
that must be resolved to integrate indexed variables 
into our scheme. 

We have three mai n goals when writi ng these col umns 
First, we try to present projects that can help improve the 
quality and productivity of Smalltalk programmers, and 
we hope that you find these ActiveVariables useful for ex¬ 
ploring and debugging your code. Second, we try to do 
some interesting and perhapsunusual Smalltalk program¬ 
ming, to give you an idea ofthethings that are possible. In 
this column we leveraged the LightweightClasses and 
MethodProducers of our previous articles to implement 
ActiveVariables. We also showed another way to specialize 
the compilation process for a very particular need. We 
want to del ve i nto the heart of the Smal Ital k envi ronment 
to help you understand it better and see possible ways to 
extend it for your own benefit. This month we spent most 
of our time discussing new code, but in the process we 
hope you learned a littleaboutBehaviors and the compila¬ 
tion process. Finally, we are interested in hearing from you 
ifyou have comments or questions Are we achievingour 
goalsasfarasyouareconcerned?Are there particular areas 
of the envi ronment you'd I ike to understand, or advanced 
projects you'd like to see implemented? If you have any 
thoughts or feedback, please send them to Bob FI inkle by 
emailathinkle@primenet.com. §1 
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